EP1 420604 



Title: 

Traffic load management method based on the exchange of service specific 
free capacity information elements among radio access network controllers 

Abstract: 

In a mulil-RAT network each radio network controller RNC or BSC calculates new service 
specific Free Capacity Information Elements (IEs) and put them together with: 
standardised Cell Capacity for user traffsc, total Load Value, RT Load Value, NRT Load 
Value, etc. Into one or more messages directed to the neighbouring domains of other 
radio netwcrk controllers of the same cr another RAT. The new lEs 5 as the other lEs 5 are 
exchanged over existing Interfaces: iu 5 lur, lur-g ? A ? etc, Real Time (Streaming and 
Conversational) and Non RT (Interactive and Background) groups of services are 
considered separately for uplink and downlink. The total cell capacity Is configured 
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(54) Traffic load management method based on the exchange of service specific free capacity 
information elements among radio access network controllers 



(57) In a multi-RAT network each radio network con- 
troller RNC or BSC calculates new service specific Free 
Capacity Information Elements (lEs) and put them to- 
gether with: standardised Cell Capacity for user traffic, 
total Load Value, RT Load Value, NRT Load Value, etc. 
into one or more messages directed to the neighbouring 
domains of other radio network controllers of the same 
or another RAT. The new lEs, as the other lEs, are ex- 
changed over existing interfaces: lu, lur, lur-g, A, etc. 
Real Time (Streaming and Conversational) and Non RT 
(Interactive and Background) groups of services are 
considered separately for uplink and downlink. The total 
cell capacity is configured among: RT Dedicated Capac- 
ity (C d(RT) ), Nrt Dedicated Capacity (C d(NRT) ), RT/NRT 
Shared Capacity (C s(RT/NRT) ) which is a percentage of 
the total cell capacity that can be shared between RT 
and N RT services. The actual occupation of the cell ca- 
pacity is calculated for: Occupied Capacity for RT serv- 



ices (C o(RT) ) and Occupied Capacity for NRT services 
(C o(NRT) ). The Occupied Capacity for RT services is dis- 
tributed as follows: Occupied RT Dedicated Capacity 
( c d(RT), o) and RT/NRT Shared Capacity occupied by 
RT services (C s(RT/NRT) o(RT) ). The Occupied Capacity 
for NRT services is distributed as follows: Occupied 
NRT Dedicated Capacity (C d(NRT) 0 ) and RT/NRT 
Shared Capacity occupied by NRT services 
(C S (rtynrt), o(nrt))- The Occupied RT/NRT Shared Ca- 
pacity, or C S(RT7NRT) 0 is obtained by adding 

C s(RT/NRT),o(NRT) to C s(RT/NRT), o(RT)- Finallv tne tne 

service specific Free Capacity Information Elements 
(lEs) are calculated for RT and NRT as in the following: 



• RT Free Capacity IE = 

( C d(RT),o + C s(RT/NRT),o); 

• Nrt Free Capacity IE = 

( C d(NRT,o + C s(RT/NRT),o)- 
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Description 

FIELD OF THE INVENTION 

[0001] The present invention relates to the field of 
Public Land Mobile Networks (PLMN) and more pre- 
cisely to a traffic load management method based on 
the exchange of service specific free capacity Informa- 
tion Elements among Radio Access Network Control- 
lers. The invention is also referred to a centralised dy- 
namical resource reservation method based on the ex- 
change of service specific capacity setting in a mul- 
ti-RAT network. 

BACKGROUND ART 

[0002] With the next introduction of 3 rd Generation 
UMTS (Universal Mobile Telecommunication System) 
systems the multi-RAT (Radio Access Technology) op- 
portunities will be putted in foreground. The former 2 rd 
Generation PLMN (Public Land Mobile Network) in- 
cludes: GSM 900 MHz, DCS 1 800 MHz (Digital Cellular 
System), GSM EDGE (Enhanced Data rates for GSM 
Evolution), GPRS (General Packet Radio Service); PCS 
(Personal Communication System), etc. In the new 3 rd 
Generation UMTS two CDMA radio access techniques 
have been defined, respectively known as: TDD (Time 
Division Duplex) UTRA (UMTS Terrestrial Radio Ac- 
cess), in which transmission directions are distin- 
guished in the time domain, and FDD (Frequency Divi- 
sion Duplex) UTRA, in which transmission directions are 
distinguished in the frequency domain. The FDD UTRA 
is used by the WCDMA (Wide band Code Division Mul- 
tiple Access) system. The TDD UTRA technique fore- 
sees in its turn two options: a HCR (High Chip Rate) 
TDD of 3.84 Mcps, and a LCR (Low Chip Rate) TDD of 
1 .28 Mcps. The Applicant and CWTS (Chinese Wireless 
Telecommunication Standards) committee are further- 
more engaged in the development of a TD-SCDMA 
(Time Division - Synchronous Code Division Multiple 
Access), standard which is based on the 3GPP 1.28 
Mcps TDD physical layer and reuses much of the 
GSM-GPRS higher layer functions and procedures, of- 
fering the operators a technology able to run on most of 
the deployed GSM network elements. 
[0003] Both 2 nd and 3 rd Generation PLMNs are stand- 
ardized by international authorities whose aim is that of 
making the operation of the systems of the various man- 
ufacturers each other compatible. In particular: GSM is 
described in the relevant Technical Reports (TR) issued 
by the Special Mobile Group (SMG) of the European Tel- 
ecommunications Standards Institute (ETSI), while 
UMTS is described in the Technical Specifications (TS) 
issued by the 3rd Generation Partnership Project 
(3GPP) in the ambit of the ITU-T (International Telecom- 
munication Union). At the time of writing, the SMG does 
not exist anymore and the related GSM work has been 
taken over by 3GPP that incorporate standardisation of 



both GSM and UMTS systems. 

[0004] Fig.1 shows a multi-RAT (Radio Access Tech- 
nology) PLMN that will be soon completed in Europe. 
The new Universal Mobile Telecommunications System 

5 (UMTS) shares the existing GSM (Global System for 
Mobile communications) Core Network CN with the 
GPRS service. The Core Network CN is connected to 
one or more BSS (Base Station Subsystem) of the GSM , 
and to one or more RNS (Radio Network Subsystem) of 

10 an UTRAN (Universal Terrestrial Radio Access Net- 
work). The UMTS system of fig.1 is described in the TS 
23.002 (CN) and TS 25.401 (UTRAN). Both the UTRAN 
and BSS are connected, on air, to a plurality of User 
Equipment UE, each including a Mobile Equipment ME 

15 with a respective USIM card (UMTS Subscriber Identity 
Module). Without limitation, an UE can be either of the 
single or multistandard type. The UTRAN includes a plu- 
rality of Node B blocks each connected to a respective 
Radio Network Controller RNC by means of an lub in- 

20 terfaces. A node B includes a Base Transceiver Station 
BTS connected to the UEs through an on-air Uu inter- 
face. The upper RNC is a Serving S-RNC connected to 
the Core Network CN by means of a first lu(CS) interface 
for Circuits Switched and a second lu(PS) interface for 

25 Packet Switched of the GPRS. It is also connected to 
an Operation and Maintenance Centre (OMC). The 
RNC placed below can be a Drift D-RNC and is connect- 
ed to the upper S-RNC by means of an I ur interface. The 
UTRAN with the served UEs constitute a Radio Network 

30 Subsystem (RNS) disclosed in TS 23.1 1 0. 

[0005] The GSM - BSS block includes a plurality of 
BTSs connected to a Base Station Controller BSC by 
means of an Abis Interface and to the UEs through an 
on-air Urn interface. The BSC is interfaced to the Core 

35 Network CN by means of a Gb interface (packet 
switched) and is further connected to a Transcoder and 
Rate Adaptor Unit TRAU also connected to the Core 
Network CN through an A interface. It is also connected 
to an Operation and Maintenance Centre (OMC). 

40 [0006] The CN network includes the following Net- 
work Elements: Switching Centre MSC/ Visitor Location 
Register VLR, Gateway MSC GMSC, Interworking 
Function IWF / Transcoder TC, Camel Service Environ- 
ment CSE, Equipment Identity Register EIR, Home Lo- 

45 cation Register HLR, Authentication Centre AuC, Serv- 
ing GPRS Support Node SGSN, and Gateway GPRS 
Support Node GGSN . The following interfaces are vis- 
ible inside the CN block: A, E, Gs, F, C, D, Gf, Gr, Gc, 
Gn, and Gi. The IWF block translates the lu(CS) inter- 
so face into the A interface towards MSC / VLR block. The 
TC element performs the transcoding function for 
speech compression/expansion concerning UTRAN 
(differently from GSM where this function is performed 
outside the CN network) also connected to the MSC 

55 block through the A interface. The GMSC is connected 
to the MSC /VLR through the E interface and to a Public 
Switched Telephone Network PSTN and an Integrated 
Services Digital Network ISDN. Blocks CSE, EIR, HLR, 
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AUC are connected to the MSC /VLR through, in order, 
the Gs, F, C, and D interfaces, and to the SGSN node 
through the Gf and Gr interfaces. The SGSN block is 
interfaced at one side to theS-RNC inside UTRAN block 
by means of the lu(PS) interface, and to the BSC inside 
the GSM-BSS blockthrough the Gb interface. Atthe oth- 
er side the SGSN node is interfaced to the GGSN node 
through the Gn interface. The last block is connected 
through the Gi interface to a packet data switching net- 
work of the IP (Internet Protocol) type and/or the X.25 
type. The Core Network CN of fig.1 consists of an en- 
hanced GSM Phase 2+, as described inTS 23.101 , with 
a Circuit Switched CS part and a packet Switched part 
(GPRS). Another important Phase 2+ is the CAMEL 
(Customised Application for Mobile network Enhanced 
Logic) Application Part (CAP) used between the MSC 
and CSE for Intelligent Network (IN) applications. CAP 
is described in TS 29.078. 

[0007] In operation, the MSC, so as the SGSN node, 
keep records of the individual locations of the mobiles 
and performs the safety and access control functions. 
More BSS and RNS blocks are connected to the CN 
Network, which is able to perform intrasystem hando- 
vers between adjacent RNSs or between adjacent 
BSSs, and intersystem handovers between a RNS and 
an adjacent BSS. UTRAN in respect of GSM further im- 
proves data service by making possible greaterthrough- 
puts and the asymmetrical traffic typical of the Internet 
Protocol (IP). The network of fig.1 , which only repre- 
sents a minimal part of a world-wide network, shall allow 
the routing of a telephone call inside an International 
UMTS / GSM Service Area subdivided into National 
Service Areas. By way of the hierarchical structure of 
the UMTS network, each National Service Area is sub- 
divided into the following nested domains of decreasing 
area: PLMN Service Area; MSC / SGSN Service Area; 
Location Area LA (CS-domain) uniquely defined by its 
LAI (Location Area Identity) code; Routing Area RA in- 
side the SGSN Service Area as a subset of the CS Lo- 
cation Area; Cell Area where the UE is actually located 
in the radio coverage of a target Node B or BTS. 
[0008] Many protocols are deputed to govern the ex- 
change of information at the various interfaces of the 
multi-RAT network of fig.1 . These protocols are largely 
based on the Open System Interconnection (OS I) Ref- 
erence Model for CCITT (Comite Consultatif Interna- 
tional Telegraphique et Telephonique) Applications 
(Rec. X.200). The OSI model is partitioned into seven 
layers . From the point of view of a particular layer, the 
adjacent lower layer provides a "transfer service" with 
specific features. The way in which the lower layer is 
realised is immaterial to the next higher layer. Corre- 
spondingly, the lower layer is not concerned with the 
meaning of the information coming from the higher layer 
or the reason for its transfer. Historically the problem of 
designing a well reliable signalling system has been 
posed in the PSTNs domain. For this aim a CCITT Sig- 
nalling System N° 7 has been developed to provide an 



internationally standardised general purpose Common 
Channel Signalling (CCS) system. CCS is a signalling 
method in which a single channel conveys, by means of 
labelled messages, signalling information relating to, for 
5 example, a multiplicity of circuits, or other information 
such as that used for network management. Common 
Channel Signalling can be regarded as a form of data 
communication that is specialised for various types of 
signalling and information transfer between processors 
10 in telecommunications networks. The signalling system 
uses signalling links for transfer of signalling messages 
between telephone exchanges or other nodes in the tel- 
ecommunication network served by the system. Rele- 
vant SS7 standards are published, and regularly updat- 
es ed, as ITU-T Q.7xx Recommendations. SS7 signalling 
as been gradually enriched with new functions suitable 
forthe incoming digital PLMNs, the Intelligent Networks, 
and the Packet Switch service. To support PLMNs a Mo- 
bile Application Part (MAP) has been developed by ET- 
20 si. MAP (TS 29.002) is the most important Level 4 Ap- 
plication Part, because regulates the mobility aspects of 
the users. Typical MAP functions are, e.g.: updating and 
clearance of VLR location information, storing of routing 
information in the HLR register, delivery & updating of 
25 user profiles in the HLR and VLR, IMEI (International 
Mobile Equipment Identity) check, Inter-MSC handover 
etc. 

[0009] The general protocol architecture of the signal- 
ling used in the network, includes an Access Stratum 

30 with a superimposed Non-Access Stratum (NAS). The 
Access Stratum includes Interface protocols and Radio 
protocols for exchanging User data and control informa- 
tion between the CN and the UE. These protocols con- 
tain mechanisms for transfer NAS message transpar- 

35 ently. i.e. the so-called Direct Transfer DT procedures. 
The NAS stratum includes higher levels protocols to 
handle control aspects, such as: Connection Manage- 
ment CM, Mobility Management MM, GPRS Mobility 
Management GMM, Session Management SM, Short 

40 Message Service SMS, etc. Said general protocol ar- 
chitecture is designed in horizontal layers and vertical 
planes, taken as logically independent of each other. At 
the various RAT interfaces, two main horizontal layers 
are present: an upper Radio Network Layer and a lower 

45 Transport Network Layer, in the latter is present the 
Physical Layer corresponding to the Level 1 . Three ver- 
tical planes are generally present, respectively: a Con- 
trol Plane, an User Plane, and a Transport Network Con- 
trol Plane. The User Plane includes the Data Stream(s) 

50 and the data Bearer(s) forthe Data Stream(s). Each da- 
ta stream is characterised by one or more frame proto- 
cols specified forthat interfaces. The User Plane is used 
to transport all user data, e.g.: speech data or packet 
data. The Control Plane includes several Application 

55 Protocols used for all control signalling which is proce- 
dure specific. The Control Plane also includes the Sig- 
nalling Bearer(s) for transporting the Application Proto- 
cols messages. The Transport Network Control Plane 
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is used for all control signalling within the Transport Net- 
work Layer; it does not contain any Radio Network Layer 
information. The Transport Network Control Plane acts 
as plane between the Control Plane and the User Plane, 
it enables the Application Protocols in the Control Plane 
to be total independent of the technology selected for 
data bearer in the User Plane. The Layer 1 functions are 
those to interface to the physical medium (e.g.: optical 
fibre, radio link, copper cable) to offer the clock extrac- 
tion capability and transmission quality control. The 
physical medium shall comply with some well known 
standards, i.e. SDH, SONET, Ex, Tx, etc. In the ATM 
(Asynchronous Transfer Mode) is used on Layer 2 of the 
UTRAN's Transport Network Layer; to say. for all 3 
Planes of the lu (TS 25.412), lur (TS 25.422) and lub 
(TS 25.432) interfaces. The ATM mode enables the 
transmission of Real Time (RT) data, such as speech & 
video, as well as of Non-Real Time (NRT) data, such as 
packet data, computer files, graphics. 
[001 0] Fig. 2 shows the main protocol stacks of the CS 
and PS Control Plane referred, without limitation, to the 
only UMTS network of fig. 1 . A similar figure exists even 
for the GSM part. At the bottom of fig. 2 the following 
elements: UE, Node B, D-RNC, S-RNC, CN and the re- 
spective interfaces Uu, lub, lur, lu [lu(CS), lu(PS)] are 
depicted. The bottom part of the Control Plane includes 
the Transport Layer upon which the Radio Protocols and 
the protocols of the Non Access Stratum reside. The 
Transport Layer includes the elements of the Transport 
Network Layer, to say: the L1 and L2 layers and an Ac- 
cess Link Control Application Part (ALCAP). The NAS 
protocols are also indicated in fig. 2. With reference to 
the fig. 2, the Transport Plane on the Uu interface is the 
same as described in the User Plane, it consists of Level 
1 UTRA FDD or TDD mode and Level 2 protocols MAC 
(Medium Access Control) and RLC (Radio Link Control). 
The Transport Plane on the lub, lur and lu interfaces 
again consists of the same Level 1 as described in the 
User Plane. ATM and AAL1 -3 are used as Layer 2 sig- 
nalling protocols, in particular the ALCAP application 
part. The indicated Radio Protocols are the following: 
RRC (Radio Resource Protocol), NBAP (Node B Appli- 
cation Part), RNSAP (Radio Network Subsystem Appli- 
cation Part), RANAP (Radio Access Network Applica- 
tion Part). In operation, RRC is used as Layer 3 protocol 
for control information transfer between the UE and 
UTRAN. RRC message carry all information required to 
set-up, modify, or release Radio Links (RL), which carry 
in their payload higher layer NAS signalling and enable 
UE mobility in RRC Connected mode. NBAP is used as 
Layer 3 protocol on the lub interface. It carries common 
signalling or dedicated signalling between C-RNC and 
Node Bs. RNSAP is used as Layer 3 protocol on the lur 
interface. It supports basic inter-RNC mobility and DCH 
traffic, as well as CCH traffic transmission. RANAP is 
used as Layer 3 protocol on the lu interface. It is used 
for signalling between UTRAN and the Core network 
CN. RANAP is responsible on lu for e.g.: Paging, RAB 



(RAdio Bearer) management, S-RNC relocation, secu- 
rity and overload control, and the NAS signalling trans- 
fer. The indicated NAS Protocols are the following: MM 
(Mobility Management), GMM (GPRS MM), SM (Ses- 

5 sion Management), and CM (Connection Manage- 
ment). MM supports function such as: UE attach / de- 
tach, security functions, and location/routing area up- 
dates. SM supports Packet Data Protocol (PDP) context 
activation /de-activation for PS connections. CM is used 

10 for Circuit Switched Call Control, Supplementary Serv- 
ices, and SMS support. Besides RANAP and RRC con- 
tain Direct Transfer procedures for transparent NAS 
message transfer between UEs and the Core Network 
CN. 

15 [0011] The main purpose of the network of fig. 1 is that 
to route speech signals and packet data among different 
points of a wide geographical network assuring in the 
meanwhile the possibly best Quality of Service (QoS) to 
the end user. GPRS QoS is specified in GSM 02.60 and 

20 GSM 03.60. For the aim of QoS the provided services 
enter the following classes: 

precedence class, 
delay class, 
25 - reliability class, 

peak throughput class, and 
mean throughput class. 

[0012] The service precedence class indicates the 
30 relative importance of maintaining the service commit- 
ments under abnormal conditions, for example which 
packets are discarded in the event of problems such as 
limited resources or network congestion. The prece- 
dence classes are defined in High, Medium, and Low 
35 priority. 

[0013] The delay class defines the maximum values 
for the mean delay and 95-percentile delay to be in- 
curred by the transfer of data through the GPRS network 
(s) . The delay parameter defines the end-to-end transfer 

40 delay incurred in the transmission of SDUs (Service Da- 
ta Unit) through the GPRS network(s). This includes the 
radio channel access delay (on uplink) or radio channel 
scheduling delay (on downlink), the radio channel transit 
delay (uplink and/or downlink paths) and the GPRS-net- 

45 work transit delay (multiple hops). It does not include 
transfer delays in external networks. Four delay classes 
exist. As a minimum the PLMN shall support the best 
effort delay class 4. 

[0014] The reliability class defines the probability of 
50 loss of, duplication of, mis-sequencing of, or corruption 
of SDUs. 

[0015] The peak throughput is measured in units of 
octets per second. It specifies the maximum rate at 
which data is expected to be transferred across the net- 
55 work for an individual PDP context. There is no guaran- 
tee that this peak rate can be achieved or sustained for 
any time period, this depends upon the MS capability 
and available radio resources. The network may limitthe 



25 
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subscriber to the negotiated peak data rate, even if ad- 
ditional transmission capacity is available. The peak 
throughput is independent of the delay class, that deter- 
mines the per-packet GPRS network transit delay. 
[0016] The mean throughput is measured in units of 
octets per hour. It specifies the average rate at which 
data is expected to be transferred across the GPRS net- 
work during the remaining lifetime of an activated PDP 
context. The network may limit the subscriber to the ne- 
gotiated mean data rate (e.g., for flat-rate charging), 
even if additional transmission capacity is available. A 
"best effort" mean throughput class may be negotiated, 
and means that throughput shall be made available to 
the MS on a per need and availability basis. 
[0017] UMTS QoS is specified in TS 23.107. For the 
aim of QoS the provided services enter the following 
classes: 

conversational class; 
streaming class; 
interactive class; and 
background class. 

[0018] The main distinguishing factor between these 
QoS classes is how delay sensitive the traffic is: Con- 
versational class is meant for traffic which is very delay 
sensitive while Background class is the most delay in- 
sensitive traffic class. 

[0019] Conversational class mainly regards telepho- 
ny speech (e.g. GSM). But with Internet and multimedia 
a number of new applications will require this scheme, 
for example voice over I P and video conferencing tools. 
The maximum transfer delay is given by the human per- 
ception of video and audio conversation. Therefore the 
limit for acceptable transfer delay is very strict, as failure 
to provide low enough transfer delay will result in unac- 
ceptable lack of quality. The transfer delay requirement 
is therefore both significantly lower and more stringent 
than the round trip delay of the interactive traffic case. 
[0020] Streaming class is characterised by that the 
time relations (variation) between information entities (i. 
e. samples, packets) within a flow shall be preserved, 
although it does not have any requirements on low 
transfer delay. As the stream normally is time aligned at 
the receiving end (in the user equipment), the highest 
acceptable delay variation over the transmission media 
is given by the capability of the time alignment function 
of the application. Acceptable delay variation is thus 
much greaterthan the delay variation given by the limits 
of human perception. 

[0021] Interactive class is applied when the end-user, 
that is either a machine or a human, is on line requesting 
data from remote equipment (e.g. a server). Examples 
of human interaction with the remote equipment are: 
web browsing, data base retrieval, server access. Ex- 
amples of machines interaction with remote equipment 
are: polling for measurement records and automatic da- 
ta base enquiries (tele-machines). Interactive traffic is 



the other classical data communication scheme that on 
an overall level is characterised by the request response 
pattern of the end-user. At the message destination 
there is an entity expecting the message (response) 
5 within a certain time. Round trip delay time is therefore 
one of the key attributes. Another characteristic is that 
the content of the packets shall be transparently trans- 
ferred (with low bit error rate). 

[0022] Background class is applied when the end-us- 
10 er ; that typically is a computer, sends and receives data- 
files in the background, this scheme applies. Examples 
are background delivery of E-mails, SMS, download of 
databases and reception of measurement records. 
Background traffic is one of the classical data commu- 
15 nication schemes that on an overall level is character- 
ised by that the destination is not expecting the data 
within a certain time. The scheme is thus more or less 
delivery time insensitive. 

[0023] These classes can be grouped as groups of 
20 services, for example: RT traffic service including the 
UMTS's Conversational and Streaming classes, and 
NRT traffic service including the UMTS's Interactive and 
Background classes. Separated uplink and downlink 
values are considered for the services. Uplink is intend- 
25 ed for transmissions from the UE to the Node B, or from 
the MS to the BTS. Downlink is intended the contrary 
direction of transmission. 

APPROACH TO THE TECHNICAL PROBLEM 

30 

[0024] Specially in a multi-RAT network, each radio 
network controller shall have a precise view of the actual 
traffic load capabilities concerning the neighbouring 
cells belonging to adjacent domains of other controllers. 

35 in its turn each radio network controller shall inform the 
controllers of adjacent domains about the actual traffic 
load capabilities on its own domain. This helps issuing, 
or preventing, handover or cell reselection commands 
directed to the cells of neighbouring domains. Dedicated 

40 and shared resource settings are provided at specific 
interfaces for each RAT in order to support specific serv- 
ices. For GPRS, the current system supports GPRS 
dedicated resources on TRXs that are GPRS enabled. 
For GSM, said GPRS dedicated resources are a 

45 number of TSs (timeslots). Moreover, in GSM there exist 
voice calls dedicated resources: entire TRXs that are 
not GPRS enabled. In GSM, a number of TSs can be 
configured to be shared between voice calls and GPRS 
according to one of the following options: 

50 

• GPRS has priority on the TS, 

• voice calls have priority on the TS, 

• GPRS and voice calls have the same priority on the 
TS. 

55 

[0025] For the case an incoming voice call has priority 
on a TS and needs to use it while it is being used by 
GPRS, in current implementation the GPRS service is 
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stopped and the voice call is started. Resources reser- 
vation is also possible for UMTS: codes, time slots and 
power can be allocated for certain services. For exam- 
ple, a certain number of codes can be assigned to circuit 
switched resources. 

[0026] In the scope of a Common Radio Resource 
Management, current GSM and UMTS systems are al- 
lowed to exchange cell capacity and load information 
among RNCs/BSCs. Exchange of cell load information 
for traffic management is the subject of the following 
3GPP TR 25.891, titled: "Improvement of RRM across 
RNS and RNS/BSS (Release 6)". In this document a 
functional model is proposed in which the whole set of 
radio resources for an operator is considered to be par- 
titioned into "radio resource pools". Making reference to 
the fig. 3 these radio resource pools are controlled by 
two different types of functional entities: 

RRM entity: functional entity responsible for Radio 
Resource Management of one radio resource pool, 
i.e. this characterises the radio resource pool; 
CRRM entity: functional entity responsible for a 
Common Radio Resource Management, i.e. coor- 
dination of overlapping/neighbour radio resource 
pools controlled by different RRM entities. This new 
CRRM entity is introduced to allow some kind of co- 
ordination among different radio resource pools 
whose radio resources are linked to the same geo- 
graphic area in the network. 

[0027] Interfaces and functions are foreseen between 
a CRRM entity and one or more RRM entities and be- 
tween two CRRM entities, but not between two RRM 
entities directly. Information on other systems (e.g. inter 
system measurements GSM/UTRAN) can be retrieved 
through either the Core Network interfaces or the lur-g 
interface between RNC and BSC. The functional rela- 
tionships between the entities of the functional model 
are based on two types of functions: Reporting Informa- 
tion and RRM Decision Support. Interactions of CRRM 
and RRM with O&M (Operation and Maintenance) for 
the exchange of configuration information are possible. 
With reference to the Figures 4, 5, and 6 the following 
CRRM topologies are provided: 

1 . CRRM integrated into every RNC/BSC (fig.4); 

2. CRRM integrated only in some RNC/BSCs (fig. 
5); 

3. CRRM as a stand-alone server (fig. 6) 

[0028] The approach illustrated in fig.4 is character- 
ised by the co-location of RRM and responsible CRRM 
entities. The functional interface between RRM and 
CRRM is not realised as an open interface in this solu- 
tion. Only "Reporting Information" is exchanged over 
open interfaces. The depicted solution allows to transfer 
cell capacity and load information from one RNC to one 
BSC and vice versa using the information exchange / 



common measurement procedures via the lur-g, or 
handover / relocation procedures via A / lu interface. 
Within the UTRAN the information exchange / common 
measurement procedures on lurcan be used. Only "Re- 

5 porting Information" function on the interface between 
different CRRM entities is standardised (mainly as a cell 
load exchange). The "Reporting Information" function 
between CRRM and RRM entities and the "RRM Deci- 
sion Support" is vendor specific since the CRRM entity 

10 must be integrated in every RNC/BSC which has to sup- 
port CRRM. The approach illustrated in fig.5 is charac- 
terised by the co-location of CRRM with RRM for only 
one RNC/BSC. This integrated solution is allowing for 
open interfaces between RRM and CRRM (forthe cases 

15 where RRM is not co-located with CRRM). The ap- 
proach illustrated in fig. 6 implements RRM and CRRM 
entities into separate nodes. All of the interfaces among 
RRMs and CRRMs are open. 

[0029] Thanks to the different topologies of the Fig- 
20 ures 3-6 an effective CRRM policy based approach is 
possible for load management. The introduction of an 
open interface between CRRM and both RNS and BSS 
allows the collection of traffic load information from the 
several RNCs/BSCs forthe aim of taking optimal deci- 
25 sions concerning Handovers and, in an equivalent way 
for data, Cell Reselections. CRRM entity is not sup- 
posed to be consulted for channel switching or for soft 
handover, since the RRM in RNC/BSC shall handle 
these kind of cases. The considered handovers are of 
30 the following type: between two RNCs; between two 
BSCs; between an RNC and a BSC, and vice versa, and 
more in general between two radio network controllers 
of different RATs. The basic idea behind the "Policy- 
based CRRM approach" is the standardisation of pa- 
ss rameters and information exchange over an open inter- 
face between RRM and CRRM entities. This would en- 
able the CRRM entity to provide CRRM policies to the 
RRM entities, thus allowing the traffic situation in the 
network to be dynamically adjusted on the basis of a 
40 common strategy. In this proposal the CRRM entity only 
acts as an advisor, so that the RRM entities still take the 
final decisions (RRM is the master), but based on pa- 
rameters adjusted by CRRM. According to this policy, 
while the RRM entities take the fast decisions required 
45 for each Access Request or Handover Request, the 
CRRM entity works at a slower time scale and provides 
policies to the RRM entities whenever an update is nec- 
essary. In this sense the frequency for a policy update 
depends on the traffic variations within the involved 
50 cells. The updating frequency can also be subject to 
configuration. The CRRM entity would be able to work 
on a faster time scale than O&M, in order to dynamically 
react to traffic load variations in overlapping radio re- 
source pools. The "CRRM policy based approach" de- 
55 scribes the functional relationship between CRRM and 
RRM by three functions: 

1 . CRRM triggers RRM to report measurement/load 



Patent provided by SughniegflEon, PLLC - http://www.sughrue.com 



11 



EP 1 420 604 A1 



12 



information or RRM reports initiated by the RRM en- 
tity itself. 

2. CRRM can inform RRM about CRRM related in- 
formation (e.g. : cell capacity and load situation of 
neighbour cells which are not under control of this 5 
RRM function. 

3. CRRM sets load targets for the RRM functions 
for which the CRRM entity is responsible. 

This can be obtained by the following four procedures: 10 

• Measurement Initiating Procedure (CRRM initiat- 
ed): CRRM triggers RRM to report a load measure- 
ment for a cell which is controlled by this RRM func- 
tion. The report characteristics may be e.g. periodic, 15 
on demand, or event driven (e.g. by a load level). 
The possibility to report load measurements for 
more than 1 cell at one time should be allowed. 

• Measurement Reporting Procedure (RRM initiat- 
ed): Here the RRM may report load measurements 20 
per measurement object to the CRRM which is re- 
sponsible for this RRM. 

• Neighbour Cell CRRM Information Procedure 
(CRRM initiated): Based on the measurements re- 
ceived from different RRMs the CRRM derives the 25 
"Neighbour Cell CRRM Information" (distinguished 
per cell and per service) and sends it to all possibly 
affected RRM instances (neighbour cells in this 
sense are only those neighbour cells controlled by 
neighbour RRMs, since for cells of its own RRM no 30 
support is needed). This information is then used 

by the RRM in case of a handover (if cells of neigh- 
bour RRMs are involved) to prioritise the target cell. 

• Load Target Setting Procedure (CRRM initiated): 
When a load target - which can dynamically be set 35 
by CRRM per cell - is exceeded, the serving RRM 

of the according cell takes autonomous RRM deci- 
sions based on the provided policy (Neighbour Cell 
CRRM Information, e.g. ranking of target cells). 
This concerns the following RRM decisions: 40 

Handover due to load reasons. 
Redirect due to load reasons. 

[0030] The procedure advises RRM to aim at a certain 45 
load level within a cell, however the resulting actions 
must not increase blocking and dropping rates for calls 
in the corresponding cell. 

[0031] Cell capacity and load situation parameters 
managed by said procedures constitute as many Infor- 50 
mation Elements (IE) included in respective fields of rel- 
evant messages foreseen in the specifications. The fol- 
lowing information is reported: 

Information concerning GSM and UMTS cells (al- 55 
ready available in RNSAP - 3GPP TS 25.423 V5.0.0 
and 25.413 V5.0.0) : 



Cell Capacity Class Value: in order to compare 
the capacity available for user traffic within a 
cell among different operator' cells. Divided in 
two values (one for uplink, one for downlink): 
range: [1 ..100]. 

Load Value: in order to define the total load in 
the cell, as a percentage of the capacity indi- 
cated by the Cell Capacity Class Value. Divided 
in two values (one for uplink, one for downlink): 
range: [0..100]. 

RT Load Value: in order to define the load per- 
centage due to RT services relative to the Load 
Value. Divided in two values (onefor uplink, one 
for downlink): range: [0..100]. The NRT Load 
Value is not explicitly defined in the specifica- 
tion because directly obtainable by 100-RT 
Load. 

NRT Load Information [0..3]. The abovemen- 
tioned NRT Load Value [0..100] was not felt as 
sufficient, because of the characteristics of 
NRT traffic, that can tolerate delays and non 
continuous transmission. It was therefore de- 
cided to also define a NRT Load Information 
where the different values have the following 
meaning (the following definition for the Uplink 
NRT Load Information has been taken directly 
from 25.423 v5.2.0asan example, howeverthe 
same kind of definition applies to the Downlink 
NRT Load Information): 

0: low: The Uplink NRT load is low. 

1 : medium: The Uplink NRTIoad is medium. 

2: high: Uplink NRT load is high. Probability 

to admit a new user is low. 
3: overloaded: Uplink NRT overload. The 

probability to admit a new user is low. 

packets are discarded and the source is 

recommended to reduce the data flow. 

[0032] The goal of the Cell Capacity Class Value 
would be to allow e.g. the RNC that receives this indi- 
cation to figure out (by combining this information with 
the load values) whetherthere is still free capacity in the 
cell or not, in order to decide whether the cell can be 
considered as a potential target cell for handover or not. 

OUTLINED TECHNICAL PROBLEM 

[0033] A problem exists with the above definitions of 
the Information Element: let's consider the case of a 
GSM cell where only 80% of the overall cell capacity is 
configured by O&Mto be availablefor RT services, while 
the rest is dedicated to NRT services. In case for a cer- 
tain cell the Load Value = 80% and the RT Load Value 
= 1 00%, the RT capacity would be fully occupied by the 
ongoing RT services, while the remaining 20% remains 
free and available for possibly incoming NRT services. 
Nevertheless, an RNC that would request the capacity 
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/ load information for that cell would misinterpret the val- 
ues and take wrong decisions by thinking that there is 
still free capacity for RT services in that cell, and e.g. 
choose that cell as a target cell for load reason hando- 
vers. The problem that was just highlighted is a real 
harm for the known RRM / CRRM, that could therefore 
not work properly, vanishing any expected gains. No so- 
lution currently exists for this problem. 
[0034] Moreover (apart from the problem that not the 
whole cell capacity might be available for RT traffic), the 
RT Load Value (as it is currently defined) gives informa- 
tion about the status of RT load within the cell, but it does 
not say anything about the suitability of that cell for 
handover for RT services. In the current standardisa- 
tion, only the Load Value can give some (insufficient) 
information on the availability of resources for RT serv- 
ices: the RT Load Value can not, as it is only defined as 
a percentage of the Load Value. However, even in case 
the RT Load Value would have been defined as a per- 
centage of the Cell Capacity Class Value, the RT Load 
Value would not have been able to give any additional 
information to the information already provided by the 
Load Value on the suitability of that cell for incoming 
handovers for RT services. Currently defined service 
specific Load Values are not suitable for giving sufficient 
information on the suitability of a cell for handover for a 
specific service. 

[0035] Furthermore a centralised and dynamical res- 
ervation of capacity for specific services is desirable for 
the present and future networks. The need for dynami- 
cal settings will arise from the existence of different 
kinds of multi-mode terminals: depending on the actual 
user scenario (user terminals and their access capabil- 
ities) it will be preferable to have a certain network con- 
figuration in terms of capacities reserved in each cell for 
a specific service, for example, in order to allow NRT 
services in a certain cell to fulfil certain max delay re- 
quirements. Up to now in spite of the aforementioned 
CRRM policy, the used method for capacity reservation 
for a particular service is via O&M. For example, in 
GSM-GPRS it is possible to reserve capacity for CS and 
for PS. However, O&M configuration is generally ven- 
dor-specific, it is not a dynamical process and normally 
needs a human-machine interaction, therefore not suit- 
able to follow the traffic changes within the network. 
Let's suppose of having recourse to a CRRM resource 
reservation policy, even in such a case there are not 
suggestions in the standardised Cell Capacity Class 
Value of how setting the reserved capacity for specific 
services. The insufficient Information Elements prevent 
the CRRM policy to follow the traffic changes within the 
network. 

[0036] Summarising, the actual cell capacity and load 
Information Elements (where 'load' refers to the actual 
capacity share that is being used) that are exchanged 
among RNCs/BSCs are not enough to give a reliable 
picture about the actual resource utilisation in the neigh- 
bouring cells. This could drive the RNCs/BSCs to issue 



erroneous or non-optimal handover decisions or cell re- 
selections. Besides a centralised and dynamical reser- 
vation of capacity for specific services is absent. 

5 OBJECTS OF THE INVENTION 

[0037] The main object of the present invention is that 
to overcome the drawbacks of a traffic management 
based on the exchange of currently standardised Infor- 
10 mation Elements among Radio Access Network Con- 
trollers of the same or different Radio Access Technol- 
ogies. 

[0038] Other object of the present invention is that to 
overcome the drawbacks of the current policy for the re- 
15 source reservation, and to indicate a method to provide 
a centralised and dynamical reservation of capacity for 
specific services able to follow the traffic changes within 
the network. 

20 SUMMARY AND ADVANTAGES OF THE INVENTION 

[0039] To achieve said objects the subject of the 
present invention is a traffic load management method, 
as disclosed in claim 1 . 
25 [0040] In the disclosed method in addition to the 
aforementioned standardised Information Elements for 
Cell Capacity / Load RT/NRT, new service specific 
Free Capacity Information Elements are defined to in- 
dicate the available free capacity for a given service, by 
30 taking into account the capacity that is configured for 
that service, and the actual occupation of this capacity. 
Service specific Free Capacity I Es take into account free 
capacity on both dedicated and shared resources. Serv- 
ice specific Free Capacity I Es are exchanged among dif- 
35 ferent radio network controllers to allow the issue of op- 
timal decisions concerning intra-RAT or inter-RAT 
handovers, or cell reselections for packet data. 
[0041] Other subject of the present invention is a cen- 
tralised dynamical resource reservation method, as dis- 
40 closed in a respective independent claim. 

[0042] In the disclosed method service specific ca- 
pacity settings are new parameters set by a central- 
ised CRRM entity for every RRM entity. The purpose of 
these settings is to ask the RRM to reserve a certain 
45 amount of resources for certain services. Moreover, the 
new service specific capacity settings parameters allow 
for a dynamical resource reservation to specific services 
with clear benefits on central traffic steering capabilities 
in a multi-RAT network accessed by a varying popula- 
te tion of multi-mode terminals. 

BRIEF DESCRIPTION OF THE DRAWINGS 

[0043] The features of the present invention which are 
55 considered to be novel are set forth with particularity in 
the appended claims. The invention, together with fur- 
ther objects and advantages thereof, may be under- 
stood with reference to the following detailed description 
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of an embodiment thereof taken in conjunction with the 
accompanying drawings given for purely non-limiting 
explanatory purposes and wherein: 

fig.1 (already described) shows a known diagram 
of a Multi-RAT (GSM + 3G) PLMN; 
fig.2 (already described) shows the UMTS signal- 
ling Control Plane; 

Figures 3, 4, 5, and 6 (already described) show 
some topologies for traffic management. 

DETAILED DESCRIPTION OF AN EMBODIMENT OF 
THE INVENTION 



= 80%. 

[0047] A more detailed example is the following: 

In a given cell the capacity is configured in the fol- 
5 lowing way: 

• RT Dedicated Capacity = C d(RT) = 40% of the 
total cell capacity; 

• N RT Dedicated Capacity = C d(NRT) = 20% of the 
10 total cell capacity; 

• RT/NRT Shared Capacity = C s(RT/NRT) = 40% 
of the total cell capacity that can be shared be- 
tween RTand NRT. 



10 



[0044] With reference to the Figures 3 to 6, in addition 
to the aforementioned standardised Information Ele- 
ments for Cell Capacity / Load RT/NRT, new service 
specific Free Capacity Information Elements are de- 
fined to indicate the available free capacity for a given 
service, by taking into account the capacity that is con- 
figured forthat service, and the actual occupation of this 
capacity. Service specific Free Capacity lEs take into 
account free capacity on both dedicated and shared re- 
sources. Service specific Free Capacity lEs are ex- 
changed among different radio network controllers to al- 
low the issue of optimal decisions concerning intra-RAT 
or inter-RAT handovers, or cell reselections for packet 
data. Service specific Free Capacity lEs are exchanged 
among different radio network controllers to allow the 
issue of optimal decisions concerning intra-RAT or in- 
ter-RAT handovers, or cell reselections. 
[0045] Characteristics of service specific Free Capac- 
ity lEs are: 

• Several services are considered. Possible candi- 
date services are the five GSM/GPRS QoS classes: 
precedence class, delay class, reliability class, 
peak throughput class, mean throughput class; and 
the four UMTS QoS traffic classes: conversational 
class, streaming class, interactive class, back- 
ground class. These classes can be grouped as RT 
and NRT services, as already said. HSDPA (High 
Speed Downlink Packet Access) and MBMS (Mul- 
ticast / Broadcast Multimedia Services) are other 
candidate services. 

• Separated uplink and downlink values are consid- 
ered. 

• Range is similar to the actual Load Value IE (e.g. 
[0..100]) . 

These parameters are exchanged over existing interfac- 
es (lu, lur, lur-g, A, ...) or over new interfaces. 
[0046] As an example, the usage of service specific 
Free Capacity lEs directly gives the possibility to know 
about the suitability of a target cell for handover / cell 
reselection. Referring to above discussed case, where 
20% of the total capacity is dedicated to NRT services, 
RT Free Capacity I E would be set to 0 even if Load Value 



15 Assuming Load Value = 80% and RT Load Value = 
80%, we obtain: 

• Occupied Capacity for RT services = C o(RT) = 
80*80/1 00 = 64% of the total cell capacity. We 

20 assume this capacity to be distributed as fol- 

lows: 

• Occupied RT Dedicated Capacity = 

^d(RT) o = °f tne tota ' ce " capacity; 
25 • RT/NRT Shared Capacity occupied by RT 

services = C s(RT/NRT) o(RT) = 64-40 = 24% 
of the total cell capacity. 

• Occupied Capacity for N RT services = C o(NRT j 
30 = 80*20/1 00 = 1 6% of the total cell capacity. 

We assume this capacity to be distributed as follows: 

• Occupied NRT Dedicated Capacity = C d(NRT) 0 = 
35 1 6% of the total cell capacity; 

• RT/N RT Shared Capacity occupied by N RT servic- 
es = c s(rt/nrt), o(nrt) = u °/° of the total ce " capacity. 

Therefore the Occupied RT/NRT Shared Capacity = 

40 C s(rt/nrt), o = 24+0 = 24% of tne total cell capacity. 
Therefore, the service specific Free Capacity lEs can 
be calculated as: 

• RT Free Capacity IE = (C d(RT) + C s(RT/NRT) ) - 
45 (C d( RT), o + C S(RT/NRT) , 0 ) = (40+40) - (40+24) = 1 6% 

of the total cell capacity; 

• NRT Free Capacity IE = (C d(NRT) + C s(RT/NRT) ) - 

(C d (NRT),o + C s(RT/NRT),o) = (20+40) - (16+24) = 

20% of the total cell capacity. 

50 

Nevertheless, the above service specific Free Capacity 
I Es have to be considered along with the indication com- 
ing from the Load Value that only 20% of the total cell 
capacity is still free: 

55 

• Total Free Capacity I E = 20% of the total cell capac- 
ity (however, the indication about the total free ca- 
pacity can be already calculated as 1 00 - Load Val- 
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ue). 

[0048] In operation, the method of the invention in- 
cludes the following steps: 

a) each radio network controller (e.g. RNC, BSC) 
receives from the controlled cells or from the net- 
work relevant information to set standard Informa- 
tion Elements for each controlled cells concerning 
the cell capacity for user traffic and load parameters 
for RT and NRT services; 

b) additional service specific Free Capacity Infor- 
mation Elements to indicate the available free ca- 
pacity on both dedicated and shared resources for 
a given service or groups of services are calculated 
by taking into account the capacity that is config- 
ured for that service, and the actual occupation of 
this capacity; 

c) standard and additional Information Elements 
are included into respective fields of one or more 
messages sent to the neighbouring radio network 
controllers (the controllers of the neighbouring 
cells) of the same or another radio access technol- 
ogy, in order for the latter to know about the actual 
neighbouring traffic situation with respect to each 
service; 

d) the received Information Elements are checked 
by the radio network controllers to have indication 
on the opportunity to issue or prevent handover or 
cell reselection commands towards the cells of the 
neighbouring radio network controllers of the same 
or another radio access technology. 

[0049] With reference to the Figures 3 to 6, consider- 
ing the TR 25.891 (chapter: Policy based CRRM) talks 
about a centralised CRRM entity involved in traffic man- 
agement among overlapping resources of different 
RRM entities. We define service specific capacity set- 
tings, set by a centralised CRRM entity for every RRM 
entity. The purpose of these settings is to ask the RRM 
to reserve a certain amount of resources for certain 
services. Moreover, the new service specific capacity 
settings parameters allow for a dynamical resource res- 
ervation to specific services with clear benefits on cen- 
tral traffic steering capabilities in a multi-RAT network 
accessed by a varying population of multi-mode termi- 
nals. 

[0050] Service specific capacity settings can be de- 
fined as "Reserved Capacity lEs" characterised as fol- 
lows: 

• The settings can refer to several services or group 
of services. Possible candidate services are the five 
GSM/GPRS QoS classes: precedence class, delay 
class, reliability class, peakthroughput class, mean 
throughput class; and the four UMTS QoS traffic 
classes: conversational class, streaming class, in- 
teractive class, background class. These classes 



can be grouped as RT and N RT services, as already 
said. HSDPA (High Speed Downlink Packet Ac- 
cess) and MBMS (Multicast / Broadcast Multimedia 
Services) are other candidate services. 
5 • Separated uplink and downlink values can be con- 
sidered. 

• Range is similar to the actual Cell Capacity Class 
Value (e.g. [0..100]). 

10 [0051] In case there remains capacity that is not re- 
served neither for dedicated nor for shared purposes, 
this should be considered as shared by all the services 
with the same priority. 

[0052] Given the above, another improvement is to al- 
15 low certain resources to be shared by several services 
with different priorities. This can be done in several 
ways, e.g. by the combination of the following three lEs: 

• Service Shared Resource ID: in order to allow dif- 
20 ferent Service Shared Resource IDs for different re- 
source shares of different size to be allocated in dif- 
ferent ways with different priorities among certain 
services. 

• Service Shared Resource Reserved Capacity: IN- 
25 TEGER [0..1 00] (this needs to be divided between 

Uplink and Downlink) (e.g.: 20). 

• Service Shared Resource Priority List: list of serv- 
ices (services can be RT, NRT or the 4 different QoS 
service classes) (e.g.: vector: [conversational . inter- 
so active]). 

[0053] In the shown example, 20% of cell capacity is 
given to conversational class with priority, and to inter- 
active class services in case conversational class serv- 
es ices are not occupying that resource already. 

[0054] The above idea allows to manage the GSM 
case where the remaining capacity (that is not reserved 
neither to RT nor to NRT) can be used by RT with priority 
on NRT. 

40 [0055] A further improvement is to allow/not allow 
service pre-emption in case a service with higher priority 
would be initiated while a service with lower priority is 
ongoing: the question arises whether the service with 
higher priority should take possession over the resourc- 
es es immediately (with pre-emption) or after the service 
with lower priority has concluded (without pre-emption) 
or after the service with lower priority has stopped the 
transmission (again a case that can be seen as without 
pre-emption). The abovementioned 3 lEs could be set 
50 in an RRM entity by O&M or by CRRM. 

[0056] In order to generalise, we define one single el- 
ement for the capacity settings of both dedicated and 
shared resources, organising the proposed information 
in one Capacity Setting IE, that would include the fol- 
55 lowing information: 

• Capacity Setting ID IE: 
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• Type: integer value. 

• Description: identificator of the Capacity Set- 
ting IE. 

• Uplink Capacity Share IE: 5 

• Type: Range: [0..100]. 

• Description: to indicate the amount of uplink re- 
source (uplink capacity share) for this capacity 
setting. 10 

• Downlink Capacity Share IE: 

• Type: Range: [0..100]. 

• Description: to indicate the amount of downlink 15 
resource (downlink capacity share) for this ca- 
pacity setting. 

• Service IE (N): 

20 

• Type: vector of N elements. 

• Description: Every element represents a serv- 
ice (or group of services: e.g. RT is the group 
of conversational and streaming services). At 
least one element must be indicated. Possible 25 
elements are: RT, NRT and the 4 different QoS 
service classes. In case N=1 , the Capacity Set- 
ting IE is indicating capacity dedicated to one 
element. In case N>1 , the Capacity Setting IE 

is indicating capacity shared among the listed 30 
elements. 

• Priority Indicator IE (N): 

• Type: vector of N integer values. 35 

• Description: This IE can be used only if N>1 . 
Priority Indicator IE (n) indicates the priority rel- 
ative to the element identified by Service ID IE 
(n). Priority 1 is the highest priority. Priorities 
decrease from 1 to M where N>=M>1 . When 40 
N>1 and Priority Indicator IE is not used, the 
same priority is assigned to all the elements in 
Service IE. 

• Pre-emption Indicator IE (N): 45 

• Type: vector of N boolean values. 

• Description: This IE can only be used when Pri- 
ority Indicator IE is used. Pre-emption Indicator 

IE (n) indicates whether pre-emption should be 50 
applied to the element identified by Service ID 
IE (n) in case a service with higher priority is 
requiring the resource. In case Priority Indicator 
IE is used and Pre-emption Indicator IE is not 
used, no pre-emption should be applied. 55 

Example: in the following, a complete example is given: 
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Capacity Setting IE: 

• Capacity Setting ID IE = 1 ; 

• Uplink Capacity Share IE = 30; 

• Downlink Capacity Share IE = 30; 

• Service IE = [Conversational, Streaming, NRT]; 

• Priority Indicator IE = [1 ,2,3]; 

• Pre-emption Indicator IE = [N, N, Y]; 

[0057] In the above example, the capacity setting is 
indicated by an ID=1 . The reserved capacity in uplink is 
30% of the total cell capacity, and the same applies to 
the downlink. The reserved capacity can be shared 
among Conversational, Streaming and NRT services. 
The highest priority for occupying said resource is given 
to Conversational services, second highest priority is 
given to Streaming services, last priority is given to NRT 
traffic. Pre-emption is used only to NRT traffic in case 
NRT traffic is occupying the resource and a Conversa- 
tional or Streaming service requests the resource. 
[0058] In operation, the resource reservation method 
of the invention includes the following steps: 

a) a centralised radio network controller (CRRM) re- 
ceives from the satellite radio network controllers 
(e.g. RNC. BSC) information relevant the user traf- 
fic load referred to the various services or groups of 
services active in each controlled cell, and sets in 
reply Reserved Capacity Information Elements re- 
ferred to those specific services or groups of serv- 
ices; 

b) the centralised radio network controller (CRRM) 
includes the Reserved Capacity Information Ele- 
ments into respective fields of one or more messag- 
es sent to the satellite radio network controllers, of 
the same or another radio access technology; 

c) the radio network controllers receive said Infor- 
mation Elements and reserves capacity according- 
ly- 



Claims 

1. Traffic load management method performed by 
each radio network controller (RNC, BSC) of a mo- 
bile communication network deploying one or more 
radio access technologies (GSM , UTRAN) that 
overlap over the same geographic area, including 
the steps of: 

a) receiving from the controlled cells orfrom the 
network relevant information to set standard In- 
formation Elements for each controlled cells 
concerning cell capacity for user traffic and RT 
and NRT services load; 

b) calculating a total Load Value and partial 
Load values for RT and NRT services and in- 
cluding them in as many Information Element 
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fields of one or more messages sent to the oth- 
er radio network controllers of the neighbouring 
cells having the same or another radio access 
technology; 

c) checking the traffic-related Information Ele- 
ments coming from said other radio network 
controllers (BSC, RNC) in order to decide of is- 
suing handovers or cell reselection commands 
to the neighbouring domains; 

characterised in that: 

during said calculating step b), additional serv- 
ice specific Free Capacity Information Ele- 
ments to indicate the available free capacity on 
both dedicated and shared resources for a giv- 
en service or groups of services are calculated 
by taking into account the capacity that is con- 
figured for that service, and the actual occupa- 
tion of this capacity, said additional Information 
Elements being included in additional fields of 
said message/s; 

during said checking step c), the additional In- 
formation Elements coming from said other ra- 
dio network controllers (BSC, RNC) are 
checked in order to have supplementary indi- 
cations for issuing or preventing said hando- 
vers or cell reselection commands. 

2. Traffic load management method in accordance 
with claim 1 , characterised in that the service spe- 
cific Free Capacity Information Elements are calcu- 
lated for uplink and downlink transmissions sepa- 
rately. 

3. Traffic load management method in accordance 
with claim 1 or 2, characterised in that said service 
specific Free Capacity Information Elements as- 
sume values in a range large as the actual Load 
Value. 

4. Traffic load management method in accordance 
with one of the preceding claims, characterised in 
that the total cell capacity is configured among: 

• RT Dedicated Capacity, or C d(RT) ; 

• NRT Dedicated Capacity, or C d ( NRT ); 

• RT/NRT Shared Capacity, or C S ( RT/nr -q which 
is a percentage of the total cell capacity that can 
be shared between RT and NRT services. 

5. Traffic load management method in accordance 
with the preceding claim, characterised in that the 

actual occupation of the cell capacity is calculated 
for: 

• Occupied Capacity for RT services, or C o(RT) ; 
and 
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• Occupied Capacity for NRT services, orC 0 ^ NRT j 

Traffic load management method in accordance 
with the preceding claim, characterised in that the 

Occupied Capacity for RT services is distributed as 
follows: 

• Occupied RT Dedicated Capacity, or C d(RT)o ; 
and 

• RT/N RT Shared Capacity occupied by RT serv- 
ices, or C s(RT/NRT) )0 (rt)* 

Traffic load management method in accordance 
with claim 5 or 6, characterised in that the Occu- 
pied Capacity for NRT services is distributed as fol- 
lows: 

• Occupied NRT Dedicated Capacity, or 

C d(NRT), o! and 

• RT/NRT Shared Capacity occupied by NRT 
services, or C s(RT/NRT) o(NRT ). 

Traffic load management method in accordance 
with the preceding claim, characterised in that the 

Occupied RT/NRT Shared Capacity, orC s(RT/NRT) 0 
is obtained by adding C s(RT/NRT) o(NRT) to 

C s(RT/NRT), o(RT)' 

Traffic load management method in accordance 
with the preceding claim, characterised in that the 
service specific Free Capacity Information Ele- 
ments lEs are calculated for RT and NRT as in the 
following: 

• RT Free Capacity IE = (C d(RT) + C s(RT/NRT) ) - 

( C d(RT), o + C s(RT/NRT), o) ! 

• N RT Free Capacity I E = (C d(NRT) + C s(RT/NRT) ) 

" ( C d(NRT), o + C s(RT/NRT), o)- 



40 10. Resource reservation method in a mobile commu- 
nication network deploying one or more radio ac- 
cess technologies (GSM , UTRAN) that overlap 
over the same geographic area subdivided in con- 
trol domains of as many radio access network con- 

45 trollers (RNC, BSC), interfaced to a centralised ra- 
dio access network controller (CRRM) for the aim 
of radio resource management, characterised in 
that includes the steps of: 

50 a) receiving, by the centralised radio network 

controller (CRRM), from the satellite radio net- 
work controllers (RRM) information relevantthe 
usertraffic load referred to the various services 
or groups of services active in each controlled 

55 cell; 

b) setting, by the centralised radio network con- 
troller (CRRM), Reserved Capacity Information 
Elements referred to those specific services or 
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groups of services; 

c) including, by the centralised radio network 
controller (CRRM), the Reserved Capacity In- 
formation Elements into respective fields of one 

or more messages sent to the satellite radio 5 
network controllers (RRM), of the same or an- 
other radio access technology; 

d) receiving, by the satellite radio network con- 
trollers (RRM), said Information Elements and 
provide reserved capacity accordingly in the 10 
controlled cells. 
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A traffic load management method performed by a radio 
network controller (RNC) for distributing information about 
the available free capacity of dedicated and shared 
resources for specific services. Each RNC calculates the 
available service specific free capacity of its subordinate 
cells and sends the information to the neighboring RNCs 
allowing them to control handover or cell reselection 
commands more accuratly. 



A resource reservation method performed by a centralised 
radio access network controller for commanding satellite 
radio network controllers to reserve capacity for specific 
services. 
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Claims: 1-9 
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Claim : 10 
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